en 

o 



A Syntactic-Semantic Approach to 
Incremental Verification 

Domenico BiancuUi 

SnT Centre, University of Luxembourg, Luxembourg, Luxembourg 

domenico. bianculliguni . lu 

Antonio Filieri 

Institute of Software Technology, University of Stuttgart, Stuttgart, Germany 

antonio.filieriginformatik.uni- Stuttgart .de 

Carlo Ghezzi 
K^! DEEPSE group - DEI, Politecnico di Milano, Milano, Italy 

c3 I ghezzi@elet.polinii.it 

Dino Mandrioli 

DEEPSE group - DEI, Politecnico di Milano, Milano, Italy 

mandrioligelet . polimi . it 

m 

ITi ; May 2, 2013 

Abstract 

(N 

^ . Software verification of evolving systems is challenging mainstream method- 

^d^ ' ologies and tools. Formal verification techniques often conflict with the time con- 

straints imposed by change management practices for evolving systems. Since 
changes in these systems are often local to restricted parts, an incremental verifi- 
cation approach could be beneficial. 

This paper introduces SIDECAR, a general framework for the definition of ver- 
^^ . ification procedures, which are made incremental by the framework itself. Veri- 

fication procedures are driven by the syntactic structure (defined by a grammar) 
of the system and encoded as semantic attributes associated with the grammar 
Incrementahty is achieved by coupling the evaluation of semantic attributes with 
^ , an incremental parsing technique. 

We show the application of SIDECAR to the definition of two verification pro- 
cedures: probabilistic verification of reliability requirements and verification of 
safety properties. 

KejTvords: incremental verification; syntax-driven algorithms; attribute grammars; 
operator precedence grammars. 
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1 Introduction 

Software evolution is a well-known phenomenon in software engineering. Software 
may evolve because of a change in the requirements or in the domain assumptions, 
leading to the development and deployment of many new versions of the software. 
This phenomenon is taken to extremes by new kinds of software, called open-world soft- 
ware H, built by composing heterogeneous, third-party components, whose behavior 
and interactions cannot be fully controlled or predicted. This software is required to 
react to changes in its environment, by bringing verification to run time [7] and (self-) 
adapting its behavior while it is executing. 

Incremental verification has been suggested as a possible approach to dealing with 
evolving software [13411 . An incremental verification approach tries to reuse as much 
as possible the results of a previous verification step, and accommodates within the 
verification procedure — possibly in a "smart" way — the changes occurring in the new 
version. By avoiding re-executing the verification process from scratch, incremental 
verification may considerably reduce the verification time. This may be appealing for 
adoption within agile development processes. Moreover, incremental verification may 
speed up change management, which may be subject to severe time constraints, espe- 
cially if it needs to be performed at run time, to support dynamic self-adaptation. 

This paper proposes SiDECAR (Syntax-DrivEn inCrementAl veRification), a general 
framework to define verification procedures, which are automatically enhanced with 
incrementality by the framework itself. The framework follows a syntactic-semantic 
approach, since it assumes that the software artifact to be verified has a syntactic struc- 
ture described by a formal grammar, and that the verification procedure is encoded as 
synthesis of semantic attributes [28], associated with the grammar and evaluated by 
traversing the syntax tree of the artifact. We based the framework on operator prece- 
dence grammars II19II , which allow for re-parsing, and hence semantic re-analysis, to 
be confined within an inner portion of the input that encloses the changed part. This 
property is the key for an efficient incremental verification procedure: since the verifi- 
cation procedure is encoded within attributes, their evaluation proceeds incrementally, 
hand-in-hand with parsing. 

The main contributions of the paper are: i) the definition of a methodological ap- 
proach for incremental syntactic-semantic verification procedures (SiDECAR); ii) the 
application of SiDECAR to the definition of two verification procedures: probabilistic 
verification of reliability requirements and verification of safety properties. Indeed, 
the goal of the paper is to present the general framework, which can be used to de- 
fine incremental verification procedures. The two examples are provided to show the 
generality and versatility of the approach. 

The rest of the paper is structured as follows. Section [2] introduces some back- 
ground concepts on operator precedence grammars and attribute grammars. Section[3] 
shows how SiDECAR exploits operator precedence grammars to support syntactic- 
semantic incremental verification. In section [4] we show SiDECAR at work, by pre- 
senting the two examples. In section [5] we discuss the application of the methodology 
supported by SiDECAR. Section [6] presents related work. Section [7] provides some con- 
cluding remarks. 
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Figure 1: Example of an operator grammar ('n' stands for any natural number) and its 
operator precedence matrix 

2 Background 

Hereafter we briefly recall the definitions of operator precedence grammars and at- 
tribute grammars. For more information on formal languages and grammars, we refer 
the reader to QSU and (TnH . 

2.1 Operator precedence Grammars 

We start by recalling the definition of a context-free (CF) grammar G as a tuple G = 
(Viq,Vj-,P,S), where Vj^ is ^ finite set of non-terminal symbols; Vj is a finite set of ter- 
minal symbols, disjoint from Vj^; P Q Vj^ x (Vf^ U Vj-)* is a relation whose elements 
represent the rules of the grammar; S e Vjv is the axiom or start symbol. We use 
the following naming convention, unless otherwise specified: non-terminal symbols 
are enclosed within chevrons, such as (A); terminal ones are enclosed within single 
quotes, such as '+' or are denoted by lowercase letters at the beginning of the alpha- 
bet (a, fa, c, . . .); lowercase letters at the end of the alphabet (u, v, x, . . .) denote termi- 
nal strings; e denotes the empty string. For the notions of immediate derivation (=>), 

* 
derivation (^), and the language L{G) generated by a grammar G please refer to the 

standard literature, e.g., II21II . 

A rule is in operator form if its right hand side (rhs) has no adjacent non-terminals; 
an operator grammar (OG) contains only rules in operator form. 

Operator precedence grammars (OPGs) [ 19 ] are defined starting from operator gram- 
mars by means of binary relations on Vj named precedence. Given two terminals, the 
precedence relations between them can be of three types: equal-precedence (=), takes- 
precedence (>), and yields-precedence (<). The meaning of precedence relations is anal- 
ogous to the one between arithmetic operators and is the basic driver of deterministic 
parsing for these grammars. Precedence relations can be computed in an automatic 
way for any operator grammar We represent the precedence relations in a Vj- x Vj ma- 
trix, named operator precedence matrix (0PM). An entry m^f, of an 0PM represents the 
set of operator precedence relations holding between terminals a and fa. For example. 
Fig. [IB shows the 0PM for the grammar of arithmetic expressions in Fig. [Tal Prece- 
dence relations have to be neither reflexive, nor s3Tnmetric, nor transitive, nor total. If 
an entry m^j, of an 0PM M is empty, the occurrence of the terminal a followed by the 
terminal fa represents a malformed input, which cannot be generated by the grammar. 

Definition 1 (Operator Precedence Grammars) An OG G is an OPG grammar if and 
only if its 0PM is a conflict-free matrix, i.e., for each a, fa e Vj, \m^ bl < 1. 
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Figure 2: Example of attribute grammar 



Definition 2 (Fischer Normal Form, from II12II ") An OPG is in Fischer Normal Form 
(FNF) if it is invertible, the axiom (S) does not occur in the right-hand side (rhs) of any 
rule, no empty rule exists except possibly (S) ^ e, the other rules having (S) as left-hand 
side (Ihs) are renaming, and no other renaming rules exist. 

The grammar of Fig. [la] is in FNF. In the sequel, we assume, without loss of general- 
ity, that OPGs are in FNF. Also, as is customary in the parsing of OPGs, the input strings 
are implicitly enclosed between two '#' special characters, such that '#' yields prece- 
dence to any other character and any character takes precedence over '#'. The key 
feature of OPG parsing is that a sequence of terminal characters enclosed within a pair 
< > and separated by = uniquely determines a rhs to be replaced, with a shift-reduce 
algorithm, by the corresponding Ihs. Notice that in the parsing of these grammars non- 
terminals are "transparent", i.e., they are not considered for the computation of the 
precedence relations. For instance, consider the s}Titax tree of Fig. [3] generated by the 
grammar of Fig. [Tal the leaf '6' is preceded by '+' and followed by '*'. Because '+' < '6' 
> '*', '6' is reduced to (B). Similarly, in a further step we have '+' < (B) '*' ^ '7' > '*' and 
we apply the reduction (B) => {B) '*' '7' (notice that non-terminal (B) is "transparent") 
and so on. 

2.2 Attribute Grammars 

Attribute Grammars (AGs) have been proposed by Knuth as a way to express the seman- 
tics of programming languages [28] . AGs extend CF grammars by associating attributes 
and semantic functions to the rules of a CF grammar; attributes define the "meaning" of 
the corresponding nodes in the s}Titax tree. In this paper we consider only synthesized 
attributes, which characterize an information flow from the children nodes (of a syntax 
tree) to their parents; more general attribute schemas do not add semantic power II28II . 
An AG is obtained from a CF grammar G by adding a finite set of attributes SYN and 
a set SF of semantic functions. Each symbol X e Vj^ has a set of (synthesized) attributes 
SYN{X); SYN = [Jxev SYN{X). We use the symbol a to denote a generic element of 
SYN; we assume that each a takes values in a corresponding domain T„ . The set SF 
consists of functions, each of them associated with a rule p in P. For each attribute a 
of the Ihs of p, a function /p„ e SF synthesizes the value of a based on the attributes of 
the non-terminals in the rhs of p. For example, the grammar in Fig.fTalcan be extended 
to an attribute grammar that computes the value of an expression. All nodes have only 
one attribute called value, with Ty^iue = I^- The set of semantic functions SF is defined 
as in Fig. [2l where semantic functions are enclosed in braces next to each rule: The 
+ and * operators appearing within braces correspond, respectively, to the standard 
operations of arithmetic addition and multiplication, and eval{-) evaluates its input as 
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Figure 3: Abstract syntax tree of the expression '5*4+2+6*7*8' 

a number. Notice also that, within a rule, different occurrences of the same grammar 
symbol are denoted by distinct subscripts. 

3 SIDECAR and Syntactic-semantic Incrementality 

SIDECAR exploits a syntactic-semantic approach to define verification procedures that 
are encoded as semantic functions associated with an attribute grammar. In this section 
we show how OPGs, equipped with a suitable attribute schema, can support incremen- 
tality in such verification procedures in a natural and efficient way. 

3.1 The Locality Property and Syntactic Incrementality 

The main reason for the choice of OPGs is that, unlike more commonly used grammars 
that support deterministic parsing, they enjoy the locality property, i.e., the possibility 
of starting the parsing from any arbitrary point of the sentence to be analyzed, indepen- 
dent of the context within which the sentence is located. In fact for OPGs the following 
proposition holds. 

Proposition 1 If a(A)b ^ asb, then, for every t,u, (S) =^ tasbu iff (S) ^ ta{A)bu =^ 

* 
tasbu. As a consequence, ifs is replaced by v in the context ^ta, buj, and a{A)b => avb, 

then (S) ^ ta{A)bu ^ tavbu, and (re) parsing of tavbu can be stopped at a{A)b ^ avb. 

* 
Hence, if we build — by means of a bottom-up parser — the derivation a{A)b ^ avb, 

* 
we say that a matching condition with the previous derivation a{A)b ^ asb is satisfied 

and we can replace the old subtree rooted in (A) with the new one, independently of 
the global context ^ta, buj (only the local context [[a, b]] matters for the incremental 
parsing) . 

For instance, consider the string and syntax tree of Fig. [Sj Assume that the ex- 
pression is modified by replacing the term '6*7*8' with '7*8'. The corresponding new 
subtree can clearly be built independently within the context [['+', '#']] . The matching 

condition is satisfied by '+'(B)'#' 4- '+"6"*"7"*"8"#' and '+'(£)'#' 4- '+"7"*"8"#'; thus the 
new subtree can replace the original one without affecting the remaining part of the 
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Figure 4: Incremental evaluation of semantic attributes 



global tree. If, instead, we replace the second '+' by a '*', the affected portion of syntax 

tree would be larger and more re-parsing would be necessarjo. 

In general, the incremental parsing algorithm, for any replacement of a string w 

by a string w' in the context [[t, uj, automatically builds the minimal "sub-context" 

* * 

[[ti,Ui]] such that for some (A), a{A)b ^ atiWUib and a{A)b => atiW u^b. 

The locality propert}o has a price in terms of generative power. For example, the 
LR grammars traditionally used to describe and parse programming languages do not 
enjoy it. However they can generate all the deterministic languages. OPGs cannot; this 
limitation, however, is more of theoretical interest than of real practical impact. Large 
parts of the grammars of many computer languages are operator precedence II21[ p. 
271]; a complete OPG is available for Prolog [14]. Moreover, in many practical cases 
one can obtain an OPG by minor adjustments to a non operator-precedence gram- 
mar EH]. 

In the current SIDECAR prototype, we developed an incremental parser for OPGs 
that exhibits the following features: linear complexity in the length of the string, in 
case of parsing from scratch; linear complexity in the size of the modified subtree(s), in 
case of incremental parsing; 0(1) complexity of the matching condition test. 



3.2 Semantic Incrementality 

In a bottom-up parser, semantic actions are performed during a reduction. This allows 
the re-computation of semantic attributes after a change to proceed hand-in-hand with 
the re-parsing of the modified substring. Suppose that, after replacing substring w with 

w' , incremental re-parsing builds a derivation (iV) ^ xw'z, with the same non-terminal 

* 
(N) as in {N) ^ xwz, so that the matching condition is verified. Assume also that (N) 

has an attribute a^^. Two situations may occur related to the computation of ajy: 

1. The ajv attribute associated with the new subtree rooted in {N) has the same 

value as before the change. In this case, all the remaining attributes in the rest of the 

tree will not be affected, and no further analysis is needed. 



^ Some further optimization could be applied by integrating the matching condition with techniques 
adopted in II20II (not reported here for brevity) . 

^The locality property has also been shown to support an efficient parallel parsing technique |[31, which 
is not further exploited here. 
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I {var-id) ':= 'false' 

I {var-id) ' : =' (function-id) ' ( " ) ' 

I 'if (cond) 'then' {stmtlist) 'else' {stmtlist) 'endif ' 

I 'while' {cond) 'do' {stmtlist) 'endwhile' 
{var-id) ::= ... 
(function-id) ::= ... 
(cond) ::= ... 

Figure 5 : The grammar of the Mini language 

2. The new value of a^y is different from the one it had before the change. In 
this case (see Fig. |4l) only the attributes on the path from {N) to the root (S) (e.g., 
aj^,a[r,as) may change and in such case they need to be recomputed. The values 
of the other attributes not on the path from {N) to the root (e.g., ap and Uq) do not 
change: there is no need to recompute them. 

4 SIDECAR at work 

Using SIDECAR requires to define 1) an OPG for the programming language one wants 
to support and 2) the associated attribute grammar schema corresponding to the veri- 
fication procedures that one wants to implement. In this section we use programs writ- 
ten in the Mini language, whose OPG is shown in Fig. [5j It is a minimalistic language 
that includes the major constructs of structured programming. For the sake of read- 
ability and to reduce the complexity of attribute schemas, Mini programs support only 
(global) boolean variables and boolean functions (with no input parameters). These 
assumptions can be relaxed, with no impact on the applicability of our approach. 

In the rest of this section we demonstrate the generality of the SIDECAR framework 
by means of two examples of incremental verification. The former one (Section I4.1D 
reports on probabilistic verification of reliability properties of programs that compose 
possibly faulty functions. The latter (Section [4.2D reports on verification of safety prop- 
erties of programs. We chose two simple, but rather diverse examples to demonstrate 
sidecar's versatility as a general framework. For space reasons and for the sake 
of readability, we adopt a straightforward encoding of these verification procedures 
and make several simplifying assumptions. We deliberately omit all optimizations and 
heuristics that would improve the verification, which are adopted by state-of-the-art 
tools. Nevertheless these could be accommodated in SIDECAR through richer (and 
more complex) attributes. 

To show the benefits of incrementality, for each of the verification procedures de- 
fined in the next subsections, we analyze two versions of the same example program 
(shown in Fig. [S]), which differ in the assignment at line[3j which determines the ex- 
ecution of the subsequent if statement, with implications on the results of the two 



analyses. Figure [7] depicts the syntax tree of version 1 of the program, as well as the 
subtree that is different in version 2; nodes of the tree have been numbered for quick 
reference. 

The next two subsections describe in detail the two analyses and their correspond- 
ing attribute schemas. Before presenting them, here we introduce some useful nota- 
tions. Given a Mini program P, Fp is the set of functions and Vp the set of variables 
defined within P; £p is the set of boolean expressions that can appear as the condition 
of an if or a while statement in P. An expression e e £p is either a combination of 
boolean predicates on program variables or a placeholder predicate labeled *. Here- 
after, we drop the subscript P in Fp, Vp, and Ep whenever the program is clear from 
the context. 

4.1 Probabilistic Verification of Reliability Requirements 

In this section we show how to apply SIDECAR to perform probabilistic verification of 
reliability requirements of Mini programs. Reliability is a "user-oriented" property [jS]]; 
in other words, a software may be more or less reliable depending on its use. If user 
inputs do not activate a fault, a failure may never occur even in a software containing 
defects HU; on the other hand, users may stress a faulty component, leading to a 
high frequency of failure events. Here we consider reliability as the probability of 
successfully accomplishing an assigned task, when requested. 

We observe that the verification problem presented here for Mini can be viewed 
as a high-level abstraction of a similar verification problem for service compositions in 
the context of service-oriented architectures, since the call to possibly faulty functions 
mimics the call to third-party services. 

Most of the current approaches for verification of reliability requirements use prob- 
abilistic model checking II24U33II . Software systems are translated into stochastic mod- 
els, such as Discrete Time Markov Chains (DTMCs), which are suitable to represent 
usage profiles and failure probabilities. A DTMC is essentially a finite state automa- 
ton where states abstract the program execution state, such as the execution of a task 
or the occurrence of a failure, and the transitions among states are defined through a 
probabilistic distribution. DTMCs can be analyzed with probabilistic model checkers 
such as PRISM [30] and MRMC [27]. 

To model the probabilistic verification problem in SIDECAR, first we assume that 



1 begin 

2 opA(); 

3 X := false; 
if (x==true) 

5 then opB() ; 

6 else opA() ; 
endif ; 

end 
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begin 


2 


opAO; 


3 


X := true; 


4 


if (x==true 


5 


then opB() 


6 


else opA() 


7 


endif; 


8 


end 



4 



7 



(a) Version 1 (b) Version 2 

Figure 6: The two versions of the example program 
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(S)0 
{stmlist} 1 
{stmt) 2 (stmlist) 5 

{function-id) 3 (stmt) 6 {stmlist) 10 

opA() 4 (var-id) 7 true 9 (stmt) n 

X 8 (cond) 12 {stmlist) 14 {stmlist) 18 

(^""f) 6 ] x==t rue 13 (stmt) 15 (stmt) 19 

{var-id) 7 false 9 | {function-id) 16 {function-id) 20 

I ' I 

! 'i^ I opB()17 opA()21 

Figure 7: The syntax tree of version 1 of the example program; the subtree in the box 
shows the difference (node 9) in the syntax tree of version 2 



each function / € F has a probability Prs(f) of successfully completing its execution. 
If successfully executed, the function returns a boolean value. We are interested in the 
returned value of a function in case it appears as the rhs of an assignment because the 
assigned variable may appear in a condition. The probability of assigning true to the 
Ihs variable of the statement is the probability that the function at the rhs returns true, 
which is the product Prg{f) ■ Prj(f), where Prj(f) is the conditioned probability that 
/ returns true given that it has been successfully executed. For the sake of readability, 
we make the simplifying assumption that all functions whose return value is used in 
an assignment are always successful, i.e., have Prsif) = 1. Thanks to this assump- 
tion the probability of/ returning true coincides with Prj{f) and allows us to avoid 
cumbersome, though conceptually simple, formulae in the following development. 

For the conditions e e £ of if and while statements, Prj(e) denotes the probability of 
e to be evaluated to true. In case of an if statement, the evaluation of a condition e leads 
to a probability Pr-j-(e) of following the then branch, and 1 — Prj(e) of following the 
else branch. For while statements, Prj(e) is the probability of executing one iteration of 
the loop. The probability of a condition to be evaluated to true or false depends on the 
current usage profile and can be estimated on the basis of the designer's experience, the 
knowledge of the application domain, or gathered from previous executions or running 
instances by combining monitoring and statistical inference techniques [18^]. 

The value of Pr^ie) is computed as follows. If the predicate is the placeholder 
*, the probability is indicated as Prj(*). If e is a combination of boolean predicates 
on variables, the probability value is defined with respect to its atomic components 
(assuming probabilistic independence among the values of the variables in V) : 

- e = "v==true" =^ Pr-r(e) =Prj.(v) 

- e = "v==false" ^^ Prj{e) = 1 - Prjiv) 

- e = e^Ke2 =^ Prj{e')=Prj{e{)-Prj{e{) 

- e = -16;^ ^^ Prjie) = 1 —Prri^Si) 

The initial value of Pr-j-(v) for a variable v 
assigned, it is defined as follows: 



V is undefined; after the variable is 



- v:=true =^ Pr j{v) — l 

- v:=false ^^ Prj[v) — 

. v:=f() ^ Prj[v)^PrT[f) 

The reliability of a program is computed as the expected probability value of its suc- 
cessful completion. To simplify the mathematical description, we assume independence 
among all the failure events. 

The reliability of a sequence of statements is essentially the probability that all of 
them are executed successfully. Given the independence of the failure events, it is the 
product of the reliability value of each statement. 

For an if statement with condition e, its reliability is the reliability of the then 
branch weighted by the probability of e to be true, plus the reliability of the else 
branch weighted by the probability of e to he false. This intuitive definition is formally 
grounded on the law of total probability and the previous assumption of independence. 

The reliability of a while statement with condition e and body b is determined by 
the number of iterations k. We also assume that Pr-j-(e) < 1, i.e., there is a non-zero 
probability of exiting the loop, and that Pr^^e) does not change during the iterations. 
The following formula is easily derived by applying well-known properties of probabil- 
ity theory: 

oo 

EiPrsiiwhile))) = J](Prr(e) ■Prs(&))'^ • (1 -Pr^(e)) 

fc=0 

1-Prr(e)-Prs(b) 

A different construction of this result can be found in ['15'J . 

We are now ready to encode this analysis through the following attributes: 

- SYN((S)) = SYN((stmlist)) = SYN((stmt)) = {r,'&}; 

- SYNiicond)) ^ {5}; 

- SYN({function-id)) = SYN[{var-id)) = {tj}; 
where: 

• Y represents the reliability of the execution of the subtree rooted in the node the 
attribute corresponds to. 

• # represents the knowledge acquired after the execution of an assignment. Pre- 
cisely, # is a set of pairs (v,Pr-j-(v)) with v ^V such that there are no two different 
pairs (vi,Pr7-(vi)), (v2,Prj-(v2)) € i? with v^ = V2- \i^{yx,Prj{y{)) e -^ no knowl- 
edge has been gathered concerning the value of a variable v^ . If not differently 
specified, ■Q is empty. 

• 5 represents Prj[e), with e being the expression associated with the correspond- 
ing node. 

• 17 is a string corresponding to the literal value of an identifier 

The actual value of y in a node has to be evaluated with respect to the informa- 
tion possibly available in -&. For example, let us assume that for a certain node n^, 
y("i) = -9 •Prj-(v). This means that the actual value of Y{n{) depends on the value 
of the variable v. The latter can be decided only after the execution of an assignment 
statement. If such assignment happens at node 02, the attribute "Qiji^) will contain 
the pair {v,Prj-(v)). For example, let us assume Pr-j-(v) = .7; after the assignment, 
the actual value of j{n{) is refined considering the information in '^{n-2), assuming the 
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numeric value .63. We use the notation y(-) \ •&(■) to describe the operation of refining 
the value of y with the information in i?. Given that )'(•) | = y(-), the operation will 
be omitted when '!?(•) — 0- 

The attribute schema is defined as follows: 

1. (S) ::= 'begin' {stmdist) 'end' 
riiS)) := riistmtlist)) 

2. (a) {stmdistQ) ■.:- {stmt) ';' {stmtlistj) 

YdstmtlistQ)) ■— (y({5tmt)) ■ yiistrntlist^))) \ '&[{stmt)) 
(b) {stmtlist) ::= {stmt) ';' 
Y{{stmtlist)) := Y{{stmt)) 

3. (a) {stmt):-- {function-id) 'V'Y 

r{{stmt)):=Prs[n 

with f ^ F and ri({function-id)) = / 

(b) {stmt):-- (var-id) ':="t rue' 
rastmt)) := 1, 
^((5tmt)):={{r,((var-id)),l)} 

(c) {stmt)-.-- (var-id) ':="false' 
r((stmt)) := 1, 
^((5tmt)):={(r?((var-id»,0)} 

(d) (stmt) :— {var-id) '=' {function-id) '(")' 
r((stmt)) := 1, 

'9(^{stmt)) := {{r](^{var-id)),PrT(^'q(^{function-id)))} 
with f ^ F and ri[{function-id)) = / 

(e) (stmt) :~ 'if (cond) 'then' (stmfoto) 'else' (stmfotj) 'endif 
y((5tmt)) := ^((stmtfoto)) • 5((cond)) 

+ Y{{stmtlisti ))•(!- 5((cond))) 

(f) (stmt) :~ 'while' {cond) 'do' {stmtlist) 'endwhile' 

l-5((cond)) 
7((5tmt)) := 

4. {cond) ::= .. 
5((cond)) :=Pr-j-(e), with ri{{cond)) = e 

We now show how to perform probabilistic verification of reliability properties with 
SIDECAR on the two versions of the example program of Fig. [6l In the steps of attribute 
synthesis, for brevity, we use numbers to refer to corresponding nodes in the syntax tree 
of Fig. [71 As for the reliability of the two functions used in the program, we assume 
Prs(opA) = .97, Prs(opB) = .99. 



1 - 5 ({cond)) ■ Y{{stmtlist)) 



Example Program - Version 1 




Given the abstract syntax tree in Fig. [Tj evaluation of attributes leads to the following 


values: (17 attributes omitted): 


r(2) ■=.97-, 


r(18) :=r(19); 


r(6) :=i; 


r(ll) := .99 -5(12) 


^(6) :={(x,l)}; 


+.97 -(1-5(12)); 


5(12) :=Pr^("x==l"); 


r(io) 


= r(ii); 


r(15) :=.99; 


r(5) 


= (r(6)-r(10))|i?(6) = .99; 


r(14) :=r(15); 


r(i) 


= r(2) -7(5) = .9603; 


r(19) :=.97; 


r(o) 


= r(l)= .9603. 



11 



The resulting value for 7(0) represents the reliability of the program, i.e., each execu- 
tion has a probability equal to .9603 of being successfully executed. 

Example Program - Version 2 

Version 2 of the example program differs from version 1 only in the assignment at 
line [3j which leads the incremental parser to build the subtree shown in the box of 
Fig. [71 Because the matching condition is satisfied, this subtree is hooked into node 
6 of the original tree. Re-computation of the attributes proceeds upward to the root, 
leading to the following final values: 

r(6) := 1; 

1^(6) :={{x,0)}; 

r(5) := (r(6) • r(10)) 1 1^(6) - .97; 

r(l) := y(2) • r(5) = .9409; 

r(0) := r(l) := .9409. 

In conclusion, this example shows that SIDECAR re-analyzes only a limited part of the 
program and re-computes only a small subset of the attributes. 

4.2 Verification of Safety Properties 

This section shows how to use SIDECAR to define a basic software model checking 
procedure, which solves the safety verification problem: given a program and a safety 
property, we want to decide whether there is an execution of the program that leads to 
a violation of the property. 

In software model checking, it is common to use a transition-relation representation 
of programs [25], in which a program is characterized by a set of (typed) variables, a 
set of control locations (including an initial one), and a set of transitions, from a control 
location to another one, labeled with constraints on variables and/or with program 
operations. Examples of this kind of representation are control-flow graphs [Q]] and 
control-flow automata f5) . A state of the program is characterized by a location and 
by the valuation of the variables at that location. A computation of the program is a 
(finite or infinite) sequence of states, where the sequence is induced by the transition 
relation over locations. Checking for a safety property can be reduced to the problem 
of checking for the reachability of a particular location, the error location, for example, 
by properly instrumenting the program code according to the safety specification. 

In the implementation of safety verification with SIDECAR we assume that the prop- 
erty is defined as a property automaton [ 9 ] , whose transitions correspond either to a 
procedure call or to a function call that assigns a value to a variable. From this au- 
tomaton we then derive the corresponding image automaton, which traps violation of 
the property in an error location (called ERK). 

Formally, let VA be the set of variable assignments from functions, i.e., VA = {x := 
/ I X € V and / € f }. A property automaton A is a quadruple A = {S,T,5,So) where S is 
a set of locations, T is the alphabet T = FUVA, 5 is the transition function 5: SxT ^ S, 
and So is the initial location. Given a property automaton A, the corresponding image 
automatonA' is defined as A' = {Su{ERR}, T, 5',So), where 5' = 5u{(s, t,ERR) \ (s, t) e 
S X T A -i3s' e S I (5, t,s') e 5}. An example of a property automaton specifying the 
alternation of operations opA and opB on sequences starting with opA is depicted in 
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\ opB 



YerrV 

Figure 8: A property automaton; dashed lines belong to the corresponding image au- 
tomaton 

Fig. [8j transitions drawn with a dashed line are added to the property automaton to 
obtain its image automaton. 

Instead of analyzing the program code instrumented with the safety specification, 
we check for the reachability of the error location in an execution trace of the image 
automaton, as induced by the syntactic structure of the program. 

More specifically, each location of the automaton is paired with a configuration of 
the program, which consists of a mapping of the program variables and of the traversal 
conditions for the paths taken so far. A configuration is invalid if the set of predicate 
conditions holding at a certain location of the program are not compatible with the 
current variables mapping for that location. Formally, let VM : V >-> {true, false} be 
a mapping from program variables to their value (if defined). The set of possibile 
configurations that can be reached during the execution of a program is denoted by 
C = (VM X £) u {J.}, where E is the set of boolean expressions that can appear as the 
condition of an if or a while statement and _L stands for an invalid configuration. 

Configurations of the program may change when variables are assigned a new 
value, e.g., by a direct assignment of a literal or by assigning the return value of a 
function. We use a function upd that updates a configuration and checks whether it is 
valid or not. The function upd is defined as upd: (C x V u {e} x {truejalse} U {e} x 
E U 1^} X {truejalse} U {e}) — » C. The function takes a configuration, a variable, its 
new value, a combination of boolean expressions (corresponding to a certain path con- 
dition), its new value, and returns the new configuration; the e symbol accounts for 
empty parameters. 

We call the pair (location of the image automaton, configuration of the program) an 
extended state. A safety property represented as an image automaton is violated if it is 
possible to reach from the initial extended state another extended state whose location 
component is the ERR location. Each statement in the program defines a transition 
from one extended state to another. 

For example, a procedure call determines the location component in an extended 
state by following the transition function of the image automaton corresponding to the 
call. An assignment to a variable updates the program configuration component of an 
extended state. In case a variable is assigned the return value of a function invocation, 
both components of an extended state are updated. 

Conditions in selection and loop statements are evaluated and the program config- 
uration of the corresponding extended state is updated accordingly, to keep track of 
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which path conditions have been taken. For an if statement, we keep track of which 
extended states could be reachable by executing the statement, considering both the 
then branch and the else branch. For a while statement, we make the common assump- 
tion that a certain constant K is provided to indicate the number of unrolling passes of 
the loop. We then keep track of which extended states could be reachable, both in case 
the loop is not executed and in case the loop is executed K times. 
The set of attributes is defined as: 

- SYNiiS)) = SYNiistmlist)) = SYNHstmt)) = {j}; 

- SYN((cond)) = {Y,v}; 

- SYN((var-id)) = SYN ({function-id)) = {rj}; 
where: 

• yCSxCxSxC is the relation that defines a transition from one extended state 
to another one; 

• V is a string corresponding to the literal value of an expression e e £; 

• 17 is a string corresponding to the literal value of an identifier 

For the y attribute of (cond) we use the symbol y^ (respectively 7^) to denote the 
attribute y evaluated when the condition {cond) is true (respectively, false) . We also 
define the operation of composing y relations ( the o operator) as follows: Yi° Y2 = 
(5i,Ci,S2,C2) such that there exist (si,Ci,5;,C;) e y-^ and (s;,C;, 53,02) ^r2- 

The attribute schema is defined as follows, where we use the symbols 5,5^,52 and 
c,Ci,C2 to denote generic elements in S and C, respectively. 

1. (S) ::= 'begin' {stmtlist) 'end' 
yi{S)) - yi{stmtlist)) 

2. (a) {strntlistg) ::- {stmt) ';' {stmtlistj) 

y{{stmtlisto)) '■= y({stmt)) o y{{stmtlist2)) 
(b) {stmtlist) ■.:- {stmt) ';' 
y{{stmtlist)) := y({stmt)) 

3. (a) {stmt):-- {function-id) ' V ')' 

y({stmt)) := (s^,c,S2,c) such that there is / € F with 5(si,f) = S2 and 
ri({function-id)) = f 

(b) {stmt) ::= (var-id) ':="t rue' 

y({stmt)) := (s,Ci,s, C2) with C2 = upd(ci,ri({var-id)),true,e,e) 

(c) {stmt) ::= (var-id) ':="false' 

y({stmt)) := (s,Ci,s, C2) with C2 = upd(ci, ri({var-id)), false, e , e) 

(d) {stmt) ::= {var-id) '=' {function-id) '(")' 

y({stmt)) := (s^,C;^, 52,02) U (s^, 01,52,03) such that there is / e F with 
5(si,/) = S2, ri{{function-id)) = /, C2 = upd{ci, r\{{var-id)), true, e, e), 
and 03 = upd{ci, r]{{var-id)), false, e, e) 

(e) {stmt) ::- 'if (oond) 'then' {stmlistg) 'else' {stmlist^) 'endif 
y{{stmt)) ■— 7^ ((oond)) o y{{stmtlisto)) U 7^ ((oond)) o Y{{stmtlisti)) 

(f) {stmt) ■.:- 'while' (oond) 'do' {stmtlist) 'endwhile' 

yi{stmt)) := /"'^■^ o Y^i{cond)) where y'""^y = (^y^i{cond)) o yi{stmtlist))Y 

4. {cond) ::=... 

yi{cond)) := Y'^{{cond)) U y^ {{cond)) = 

(5,01,5,02) U (5,01,5,03) where 02 = upd{ci,e,e,v {{cond)), true) 
and 03 = upd{ci, e , e ,v{{cond)),false) 
We now show how to perform safety verification with SIDECAR on the two versions 
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of the example program. For both examples, we consider the safety property specified 
with the automaton in Fig. [H] 

Example Program - Version 1 

Given the abstract syntax tree depicted in Fig. [71 attributes are synthesized as follows: 

y(2) := {(qo,c,qi,c),(qi,c,£RR,c)}; 

y(6) := {s,ci,s,upd{ci,"x",true,e,e)); 

7(12) :=y'^(12)Uy^(12) := (s, q, 5, upd(ci, e, e, "x==t rue", true)) U 

{s,Ci,s,upd{ci,e,s, "x==true",/aZse)); 

rilS) := {{qi,c,qo,c) ,{qQ,c,ERR,c)}; 

r(i4):-r(i5); 

y-(19):= {{qo,c,qi,c),{qi,c,ERR,c)}; 

7(18) := r(19); 

7(11) := r^(12) o y(14) U 7^(12) o y(18) := 

(5, Ci,s, upd{ci, e, e, "x==t rue", true)) o {{q^i^.c, q^, c), (qg, c,ERR, c)} U 

(5, Ci,s, upd(ci, e, e, "x==true", false)) o { {q^, c, qi, c), {qi,c,ERR, c)} := 

{(qi, Ci, qo, upd(ci, e, e, "x==true", true)), (qg, Ci,ERR, upd^c^, e, e, "x==t rue", true)), 

{qQ,Ci,qi,upd{ci,e,e, "x==true", false)), {qi,Ci,ERR,upd(ci,E,E, " x==t rue" , false))}; 

r(10):-r(ll); 

r(5) := y(6) o ^(10) := {(q^, q, qo, upd^updic-^^, "x",true, e, s), e, e, "x==t rue", true)), 

(qo, Ci,ERR, upd(upd(ci, "x" ,true, e, e), e, e, "x==t rue", true)), 

(qO'Ci,qi,l),(qi,Ci,£iy?,l)}. 

The last two tuples of 7(5) are discarded because they contain a J. configuration. J. is 
returned by upd; according to its semantics, the evaluation of the condition "x==true" 
to false is not compatible with the previous configuration, where x is assigned the value 
true. Hence, we have: 

r(5) ■= {{qi, Ci, qo, upd^upd^Ci, "x",true, e, e), e, s, "x==t rue", true)), 
(qo, Ci,ERR, upd(upd[ci, "x" ,true, e, e), s, e, "x==true", true))}; 
ril)-- ri2) o y(5) := (qo, c, qo, updiupd(^c, "x",true, e, e), e, e, "x==t rue", true)); 
y(0) :=r(l) := (qo, c, qo, upd(upd(c, "x", true, e,e),e,e, "x==true", true)). 
The resulting 7(0) shows that the error location is not reachable from the initial ex- 
tended state. Therefore we can conclude that the property will not be violated by any 
execution of the program. 

Example Program - Version 2 

The change in version 2 of the example program affects node 9 of the subtree shown in 

the box of Fig. [71 Attribute evaluation proceeds from node 6 up to the root, as shown 

below: 

r(6) ■- {s,ci,s,upd{ci,"x", false, e,e)); 

r(5):-r(6)°r(10):={(qi,Ci,qo,l), (qo,Ci,£RK,l), 

(qo, Ci,qi, upd{upd{ci, "x" , false, e, e), e, e, " x==true" , false)) 

{qi,Ci,EER,upd{upd{ci, "x" , false, e,e),e,e, " x==true" , false)) }. 

The first two tuples of 7(5) are discarded because they contain a J. configuration. _L is 

returned by upd; according to its semantics, the evaluation of the condition " x==t rue " 
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to true is not compatible with the previous configuration, where x is assigned the value 
false. Hence, we have: 

r(5) ■= {(qo. Ci, qi, upd(upd(q, "x", false, e, e), e, e, "x==true", false)), 

(qi,Ci,ERR,upd(upd(ci, "x", false, e,e),e,e, "x==t rue", false))}; 

y(l) :=y(2)oy(5) := (qQ, c, ERR, upd(upd(c,"x", false, £,e),e,e,"x==t rue", false)); 

y(0) := y(l) := (qQ,c,ERR,upd(upd(c,"x", false, E,e),e,e,"x==true", false)). 

By looking at 7(0), we notice that the error location is now reachable, which means 

that version 2 of the program violates the safety property. 

Note that we reuse results from the analysis of version 1, since /(lO) and y(2) have 
not changed. In the analysis of version 2 we processed only 7 tuples of the state space, 
compared with the 26 ones processed for version 1. 

5 Discussion 

SIDECAR introduces a general methodology for the definition of incremental verifica- 
tion procedures. It has only two usage requirements: Rl) the artifact to be verified 
should have a syntactic structure derivable from an OPG; R2) the verification proce- 
dure has to be formalized as synthesis of semantic attributes. 

The parsing algorithm used within SIDECAR has a temporal complexity (on aver- 
age) linear in the size of the modified portion of the syntax tree. Hence any change in 
the program has a minimal impact on the adaptation of the abstract s}Titax tree too. 
Semantic incrementality allows for minimal (re) evaluation of the attributes, by pro- 
ceeding along the path from the node corresponding to the change to the root, whose 
length is normally logarithmic with respect to the length of the program. Thus the 
use of SIDECAR may result in a significant reduction of the re-analysis and semantic 
re-evaluation steps. The saving could be very relevant in the case of large programs 
and rich and complex attribute schemas. 

We emphasize that the two examples showed in the previous section were not de- 
signed to be directly applied to real-world software verification, but to give an intuitive 
glimpse of the generality of the approach. The generality and flexibility of OPGs allow 
for using much richer languages than the Mini example used in this paper Moreover, at- 
tribute grammars — being Turing complete — enable formalizing in this framework any 
algorithmic schema at any sophistication and complexity level, posing no theoretical 
limitation to using SIDECAR. For example, more expressive language constructs and 
features (like procedure calls, procedures with reference parameters and side effects, 
pointers, shared-variable concurrency, non-determinism) could be accommodated with 
attribute schemas more complex both in terms of the attributes definition and in terms 
of the type (e.g., AGs with references II22II could be useful when the "semantics" of a 
program element is not confined within its "syntactic context") . More generally, richer 
attribute schemas could support both new language features and different verification 
algorithms (e.g., abstraction-based techniques for the case of verification of safety prop- 
erties, or more realistic assumptions on the probabilistic system behavior for the case of 
verification of reliability requirements). In all these scenarios incrementality would be 
automatically provided by the framework, without any further effort for the developer 

We acknowledge that some technical issues should be faced when using SIDECAR 
in non-trivial practical cases. First, existing grammars could need to be transformed 
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to satisfy requirement Rl : the transformation (especially when automated) might re- 
duce the readability of the grammar and could impact on the definition of attribute 
schemas. Expressing verification procedures as AGs (to satisfy requirement R2) could 
be a non- trivial task too: for instance, developers might simply be not familiar with the 
programming paradigm required by AGs; the reuse of known verification algorithms 
might be more or less straightforward and/or effective in the context of AG. We em- 
phasize, however, that such a non-trivial effort is typically done once for all at design 
time, possibly in cooperation with domain experts. When the system is in operation, 
developers should only care about applying the changes and automatically (and incre- 
mentally) verifying their effects. 

The generality of the methodology advocated by SIDECAR widens the scope of ap- 
plication to a number of scenarios. For example, at design time, SIDECAR (possibly 
integrated within IDE tools) can effectively support designers in evaluating the im- 
pact of changes in their products, in activities such as what-if analysis and regression 
verification, very common in agile development processes. Existing techniques for au- 
tomated verification based either on model checking or on deductive approaches, as 
well as their optimizations, could be adapted to use SIDECAR, exploiting the benefits 
of incrementality. At run time, the incrementality provided by SIDECAR could be the 
key factor for efficient online verification of continuously changing situations, which 
could then trigger and drive the adaptation of self-adaptive systems [jTj] . As another in- 
stance of the approach's generality, similarly to the probabilistic verification described 
in section |4.1[ other quantitative properties, such as execution time and energy con- 
sumption, could be verified with SIDECAR. Furthermore, SIDECAR could also bring at 
run time the same analysis techniques so far limited to design time because of efficiency 
reasons. 



6 Related Work 

In this section we present related work in two parts. First, we discuss work that ad- 
dresses incrementality in verificatioro in general; next, we discuss other incremental 
approaches in the fields of the two examples presented here, namely probabilistic veri- 
fication and safety program verification. 

Different methodologies have been proposed in the literature as the basis for incre- 
mental verification techniques. They are mainly grounded in the assume-guarantee [12611 
paradigm. This paradigm views systems as a collection of cooperating modules, each 
of which has to guarantee certain properties. The verification methods based on this 
paradigm are said to be compositional, since they allow reasoning about each module 
separately and deducing properties about their integration. If the effect of a change 
can be localized inside the boundary of a module, the other modules are not affected, 
and their verification does not need to be redone. This feature is for example exploited 
in moil , which proposes a framework for performing assume-guarantee reasoning in 
an incremental and fully automatic fashion. Assume-guarantee based verification has 
been exploited also for probabilistic reasoning (e.g., in [i31i1 ). even though we are not 
aware of approaches using it in an incremental fashion. 



^Incidentally, the use of the term incremental model checking in the context of bounded model check- 
ing |[6l has a different meaning, since it refers to the possibility of changing the bound of the checking. 
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Focusing now, more specifically, on incremental probabilistic verification, a known 
technique to achieve incremental verification is parametric analysis [13. 1. With this 
technique, the probability values of the transitions in the model that are supposed to 
change are labeled with symbolic parameters. The model is then verified providing 
results in the form of closed mathematical formulae depending on the symbolic pa- 
rameters. As the actual values for the parameters become available (e.g., during the 
execution of the system), they are replaced in the formulae, providing a numerical 
estimation of the desired reliability. Whenever there is a change of the values of the 
parameters, the results of the preprocessing phase can be reused, with significant im- 
provements of the verification time [,17,] . The main limitation of this approach is that 
a structural change in the software invalidates the results of the preprocessing phase, 
requiring the verification to start from scratch, with consequent degradation of the 
analysis performance. 

Parametric analysis is reminiscent of the notion of partial evaluation, originally in- 
troduced in [|16|] . Partial evaluation can be seen as a transformation from the original 
version of the program to a new version called residual program, where the properties 
of interest have been partially computed against the static parts, preserving the depen- 
dency on the variable ones. As soon as a change is observed, the computation can be 
moved a further step toward completion by fixing one or more variable parts according 
to the observations. 

Concerning related work on incremental safety verification, other approaches based 
on (regression) model checking reason in terms of the representation (e.g., a state- 
transition system) explored during the verification, by assessing how it is affected by 
changes in the program. The main idea is to maximize the reuse of the state space 
already explored for previous versions of the program, isolating the parts of the state 
space that have changed in the new version. The first work in this line of research 
addressed modal mu-calculus II35II . Henzinger et al. II23II analyze a new version of the 
program by checking for the conformance of its (abstract) state space representation 
with respect to the one of the previous version. When a discrepancy is found, the 
algorithm that recomputes the abstraction is restarted from that location. Depending 
on where the change is localized in the program text, the algorithm could invalidate — 
and thus recompute — a possibly large portion of the program state space. Similarly, 
incremental approaches for explicit-state model checking of object-oriented programs, 
such as [32J and [36J, analyze the state space checked for a previous version and 
assess, respectively, either the transitions that do not need to be re-executed in a certain 
exploration of the state space, or the states that can be pruned, because not affected 
by the code change. These approaches tie incrementality to the low-level details of 
the verification procedure, while SIDECAR supports incrementality at a higher level, 
independently on the algorithm and data structures defined in the attributes. Conway 
et al. mill define incremental algorithms for automaton-based safety program analyses. 
Their granularity for the identification of reusable parts of the state space is coarse- 
grained, since they take a function as the unit of change, while SIDECAR has a finer 
granularity, at the statement level. A combination of a modular verification technique 
that also reuse cached information from the checks of previous versions is presented 
in II29II for aspect-oriented software. 

In conclusion, the syntactic-semantic approach embedded in SIDECAR does not 
constrain incrementality depending on on the modular structure of the artifacts, as 



18 



instead required by assume-guarantee approaches. Furthermore, it provides a general 
and unifying methodology for defining verification procedures for functional and non- 
functional requirements. 

7 Conclusion and Future Work 

Incrementality is one of the most promising means to dealing with software evolution. 
In this paper we addressed the issue of incrementality in verification activities by in- 
troducing SIDECAR, a framework for the definition of verification procedures, which 
are automatically enhanced with incrementality by the framework itself. SIDECAR sup- 
ports a verification procedure encoded as synthesis of semantic attributes associated 
with a grammar. The attributes are evaluated by traversing the syntax tree that reflects 
the structure of the software system. By exploiting incremental parsing and attributes 
evaluation techniques, SIDECAR reduces the complexity of the verification procedure 
in presence of changes. We have shown SIDECAR in use to define two kinds of verifi- 
cation, namely probabilistic verification of reliability properties and safety verification 
of programs. 

Future work will address several directions. We want to support run-time changes 
of the language (and thus the grammar) in which the artifact to be verified is de- 
scribed, motivated by advanced adaptiveness capability scenarios. We also want to 
support changes in the properties to be verified, and still exploit the benefit of incre- 
mental verification. We will continue our work to develop an incremental verification 
environment — by incorporating improvements to exploit parallelism [3J and to apply 
finer incremental parsing techniques — and will conduct experimental studies on real- 
world applications to quantify the effectiveness of SIDECAR in the definition and the 
execution of state-of-the-art verification procedures, identifying the kind of verification 
procedures for which the SIDECAR approach is more cost-effective. We will also inves- 
tigate the pragmatic issues discussed in section[5j i.e., what can be reasonably encoded 
using OPGs and AGs. Finally, we plan to exploit SIDECAR to introduce verification- 
driven development in iterative and/or agile development processes. 
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